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Description 

The invention relates to a data exchange system 
comprising at least one portable data processing unit 
comprising data communication means, processing s 
means and memory means, the later comprising an ex- 
ecutive program. 

European patent application EP-A1 -0,466,969 dis- 
closes a data exchange system comprising an IC card 
supporting multiple applications and a terminal. The IC 
card comprises a ROM for storing basic functions, e.g. 
crypto algorithms, an application independent common 
data field ("Gemeinschaftsdatenfeld"), and an applica- 
tions data field ("Anwendungsdatenfeld") with a control 
list ("Steuerliste"). Each protocol forms a combination of 
a set of basic functions and possible intermediate con- 
ditions, determined by the control list of the chosen ap- 
plication. 

International patent application WO-A-87/07063 
discloses a system for a portable data carrier having 
multiple application files. One of the most important ap- 
plications of such a portable data carrier is a smart card 
suitable for multiple applications. The known data carri- 
er is described as a carrier of hierarchically structured 
data with security features to support multiple applica- 
tions on the same data carrier. Applications are seen as 
sets of data. The patent application describes an imple- 
mentation of an hierarchical file system on a data carrier 
to store alterable data in combination with an hierarchic 
set of access permissions. The data carrier responds to 
a set of common commands. File access permissions 
are distinct for different operations and granted in de- 
pendence on password verification. A password verifi- 
cation attempt counter is introduced as well as the pro- 
vision of destruction of stored data as sanction against 
too many attempts of access. The known data carrier is 
presented primarily as a storage device and not as a 
processor. Only very simple functions may be per- 
formed by the executive program such as binary logic 
operation. It is not possible to allow the performance of 
an unspecified set of operations on request of a terminal 
communicating with the data carrier. The only security 
option is the introduction of password verification. No 
other access condition verifications are possible within 
the known system. Besides, each application of the data 
carrier has its own file within the memory means of the 
data carrier. No special measures are taken to enhance 
the efficiency of the available memory space which, es- 
pecially on smart cards, is very restrictive and therefore 
sets limits to the number of possible applications. 

EP-A-0,479,655 relates to the implementation of 
access condition checks in smart cards. One specifica- 
tion technique for that is disclosed, however, it is desir- 
able to provide for measures to in elude the possibility 
of other access condition verifications. 

EP-A-0,361 ,491 relates to a chip card programming 
system to allow protected (re)programming of cards. It 
describes the use of write-once-access conditions to 



control access of parts of the programmable memory to 
be programmed. In this way the number of applications 
on a single card can be extended. Verification of the ac- 
cess conditions with a variety of techniques including 
cryptographic protocols is described. 

EP-A-0,292,248 relates to loading of applications 
on a smart card using an unalterable operating system 
program. It includes the implementation of a data ac- 
cess condition enforcement method using memory 
zones with assigned access attributes. Specific access 
conditions are "write-once" (which is only described im- 
plicitly) and "execute-only". 

US-A-4,874,935 relates to card programming using 
a data dictionary where the data dictionary describes the 
layout of data elements stored in the card's memory. Da- 
ta dictionaries are commonly understood to differ from 
directories in that they not only describe data actually 
stored, but also data which will be stored later. In addi- 
tion, data dictionaries usually include a description of 
the data format. In compiled format data dictionaries are 
used in database management systems where they are 
stored on the hard disc as part of the database. They 
are also found in the object load files resulting from pro- 
gram compilation in software development environ- 
ments. However, the patent does not claim a represen- 
tation of data dictionaries particularly suited for smart 
cards. 

The main object of the present invention is to 
present means to cope optimally with the restrictions im- 
posed by limited physical dimensions of available mem- 
ory space on portable data processing units, especially 
smart cards. 

A further object of the present invention is to offer a 
more general mechanism of protected loading of pro- 
gram codes and to allow such a loading for multiple pro- 
grams each for one application of each portable data 
processing unit. 

Moreover, the present invention is directed to the 
provision of the use of access condition verifications not 
prescribed by the manufacturer of the portable process- 
ing unit but chosen by the application designer to suit 
his particular needs. 

Therefore the system according to the invention is 
characterized in that the memory means further com- 
prises at least one interaction context containing the fol- 
lowing coherent data structure: 

a. a set of basic communication primitives which are 
accepted whenever the data processing unit com- 
municates with a similar unit, said primitives at least 
including a primitive used to selectively enter one 
of the said interaction contexts; 

b. a set of procedural descriptions defining the ac- 
tions to be performed in response to each of the ac- 
cepted communication primitives, at least compris- 
ing a first procedural description to be performed 
upon activating the interaction context, and a last 
procedural description to be performed immediately 
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before deactivating the context; 

c. a, possibly empty, set of data elements either per- 
manently stored or computed, which are available 
for use when procedures as defined in the proce- 
dural descriptions are performed; 5 

d. a, possibly empty, set of references to data ele- 
ments, which references are associated to the pro- 
cedural descriptions, said data elements are also 
accessible to possibly further interaction contexts 
and are available for use when procedures as de- 10 
fined in the procedural descriptions are performed; 

e. a, possibly empty, data list comprising a list of 
references to data elements which are available for 
explicit reference as part of a communication prim- 
itive to be used by the procedural description asso- *5 
ciated with the communication primitive; 

f . a set of access conditions associated to the data 
elements which are referenced in association to the 
procedural descriptions; 

g. a set of access conditions associated to the list 20 
of data references in the data list. 

By defining data within the memory means of the 
portable processing unit in such a way the processing 
unit is really organized as a processor, i.e. it not only 2s 
allows logical operations but it performs processes 
which may be loaded in the processing unit by persons 
authorized to do so, e.g. a staff member of a bank. By 
providing procedures which may provide arbitrary com- 
plex operations in response to received commands and 30 
providing an explicit list of stored data elements which 
are addressable as part of such commands the commu- 
nication bandwidth can be optimally used; resulting in a 
reduced number of commands exchanged. With a sys- 
tem according to the invention many actual uses of the 35 
system will but require the exchange of two commands. 
The only thing that is fixed is the structure within the 
memory means which is defined in such a way that sev- 
eral applications of the unit may be added in a very ef- 
ficient way, i.e. by using as little additional memory 40 
space as possible. This is especially of prime impor- 
tance if the unit is a smart card which is severely limited 
as regards available memory space. Besides, the struc- 
ture according to the invention offers all possibilities to 
include security measures in order to inhibit unauthor- 45 
ized people from access to processes or data that they 
are not entitled to use. 

In a first preferred embodiment the data exchange 
system defined above is characterized in that the mem- 
ory means further comprises at least two interaction so 
contexts, at least one application description and a 
memory element storing a reference to the interaction 
context currently being in force, each application de- 
scription comprising: 

55 

a. a data list comprising references to data ele- 
ments, which references may be accessible to two 
or more interaction contexts and may be extended 



by additional data elements; 
b. a further set of access conditions associated to 
said references or to said additional data elements 
and defining restrictions of use. 

By these measures all references to data elements 
which are common to different interaction contexts are 
accessible for all those interaction contexts, so they only 
need be stored once saving memory space. Also com- 
mon access conditions to said data references are ac- 
cessible to predetermined interaction contexts. There- 
fore, also these common access conditions need only 
be stored once thereby saving memory space and en- 
hancing efficiency. 

Each application description may also comprise a 
procedure library comprising units of executable code 
which can be used by procedural descriptions of each 
interaction context associated to each of said applica- 
tion descriptions. 

Preferably, the processing unit is suitable for at least 
two applications with use of little additional memory 
space. To obtain this object the data exchange system 
according to the invention is characterized in that the 
memory means comprises at least two application de- 
scriptions and units of executable code which can be 
used by procedural descriptions of each interaction con- 
text within each application description or by each unit 
of executable code of each procedure library within each 
application description. 

Preferably, the units of executable code in the pro- 
cedure library are enhanced by including a specification 
of the use of their operational parameters into classes 
relating to attributes pertaining to data elements which 
can be passed as actual value in a computation, which 
computation only proceeds if the data attributes and pa- 
rameter classes match. This is an efficient way of veri- 
fication of access conditions both on data level and on 
function level for which a very efficient implementation 
exists. 

More reliability of the system is offered if the data 
exchange system according to the invention is charac- 
terized in that the executive program comprises a refer- 
ence to a default interaction context which is used to 
initialise the memory element storing a reference to the 
interaction context currently being in force, in order to 
carry out a final action after a detection of an internal 
inconsistency in a recovery to a normal, state of opera- 
tion or whenever the executive program is active and no 
explicit interaction context has been specified by a com- 
munication primitive received from an opposite data 
processing unit. 

In order to enhance the security of data and func- 
tions within the processing unit the data exchange sys- 
tem according to the invention may be characterized in 
that the memory means comprises an interaction con- 
text dedicated to comprise Personal Identification Num- 
bers and that the executive program is arranged to verify 
Personal Identification Numbers supplied by a user of 
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the data exchange system. 

Advantageously the Personal Identification 
Number management interaction context and the de- 
fault context can be implemented as part of the same 
device holder application. Support of this application by s 
most devices with which a device according to the in- 
vention communicates would give the device owner the 
opportunity to review his personal data as stored in the 
device memory, for instance a smart card holder could 
be allowed to modify his PIN at any smart card terminal 
which provides an appropriate user interface. 

Each application description may comprise a list of 
numeric values which is constructed to provide identifi- 
ers for all interaction contexts and comprises at least a 
first numeric value indicating an application type, a sec- 
ond numeric value indicating a unique identification of 
the entity providing the application, a third numeric value 
indicating the nature of the application description and 
further numbers each uniquely referring to one interac- 
tion context associated with the application description. 

The string of numeric values uniquely referring to 
an interaction context provides a means of establishing 
interoperability between two communicating devices 
which is more efficient than is currently envisaged for e. 
g. smart cards in relegating to the application providing 
entity the responsibility to assign unique values to each 
interaction context while leaving assignment of unique 
numbers to entities and application to relevant bodies 
of sectoral and international co-operation respectively. 
With benefit the application providing entity can assign 
the unique context numbers to incorporate implementa- 
tion version and secret key generation information. 

The data communication means may be arranged 
to structure data exchange in blocks of data comprising 
at least two parts, a first part being data qualified as op- 
erational in that it is used to influence the nature of the 
operations performed by a command as indicated by a 
communication primitive or to influence the nature of da- 
ta resulting from operations carried out, a second part 
being qualified as security in that it is used to determine 
the appropriateness of performing an operation or of the 
acceptability of data within the operational part, to be 
used in the operation or to prove completion of the op- 
eration or correctness of the resulting data. 

Such appropriateness, acceptability, proof and cor- 
rectness being obtained by performing relevant crypto- 
graphic operations on the data. Authentication and data 
protection are thus made an integral part of the com- 
mand execution providing better security than obtaina- 
ble in current systems e.g. smart cards. 

The executive program may be arranged to per- 
form, upon accepting a communication primitive to per- 
form operations specified in the current interaction con- 
text, each operation as part of a predetermined and fixed 
sequence of actions each of which is specified sepa- 
rately as part of a procedural description associated to 
the accepted communication primitive, which actions 
comprise at least the following actions: 



a. authorization of the use of the communication 
primitive; 

b. decryption of operational data or any part of it; 

c. performing a command with any input data; 

d. encryption of any operational data resulting from 
any operation performed; 

e. computation of a proof of completion of any per- 
formed action or of correctness of the resulting data 
to be used in security computations. 

Security is further enhanced if the data processing 
unit generates a random transaction number upon ini- 
tializing data transfer, which serves as basis for crypto- 
graphic computations. 

To provide for a possibility to enter a new interaction 
context if required one communication primitive may be 
assigned a specified value which will always be inter- 
preted as a request to enter a new interaction context. 

In a further preferred embodiment the data ex- 
change system according to the invention is character- 
ized in that it comprises a further data processing unit 
comprising the same elements as the data processing 
unit as well as an application programmers interface 
which consists of program code designed to allow addi- 
tional computer programs to be implemented to give us- 
ers control over the sequence of exchanged communi- 
cation primitives or to influence the data transferred in 
them or to learn or further process the data received in 
the exchange. Development of software for systems ac- 
cording to the invention will benefit from the availability 
of an application programmers interface. 

In such a preferred embodiment of the invention the 
primitive used to enter a specified interaction context 
may comprise numeric values to be used in security cal- 
culations in subsequent communications, a first value 
generated at random by one of the processing units and 
a second value serving to identify said one processing 
unit. 

To further benefit from the current invention, each 
communication primitive may further be structured to 
consist of two or more numeric values which enhance 
the expressive power of the communication primitive for 
interpretation by the executive program. 

As a first alternative, each communication primitive 
may be composed of two or more numeric values, a first 
value being used to refer to a procedural description of 
an action associated to the communication primitive, a 
second value being composed of a fixed number of bi- 
nary values each of which is interpreted by the executive 
program as a reference to a single data element. 

As a second alternative, each communication prim- 
itive may be composed of two or more numeric values, 
a first value being used to refer to a procedural descrip- 
tion of an action associated to the communication prim- 
itive, a second value being used to determine which of 
the data elements available for external reference in an 
active interaction context will be used while performing 
responding actions in such a way that any data element 
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is selected if it contains a value that matches said sec- 
ond value. 

As a third alternative, each communication primitive 
is composed of two or more numeric values, a first value 
being used to refer to a procedural description of an ac- 
tion associated to the communication primitive, a sec- 
ond value being composed of a number of binary values 
which are assigned specific meanings by the executive 
program to be used in interpreting data formats in the 
communication primitive and in performing responding 
actions. 

The context mechanism defined above and the 
techniques it makes available leads to a wider range of 
smart card use and an approach of smart card applica- 
tion development which have a number of advantages 
over the traditional ways. 

First of all, it allows the execution of application spe- 
cific program code in a smart card without the need to 
thoroughly examine the code for potential threats to the 
security of data stored for other applications. As the ac- 
cess conditions which are stored with the data on the 
card are enforced by the card operating system without 
possibility of outside interference during execution of 
application code, a multi application card scheme does 
not need a program code vetting authority. Such author- 
ity is the only way to allow a private code execution fa- 
cility in traditional smart cards. By approving code for 
execution on a card a vetting authority incurs liabilities 
with respect to the overall system security; it makes the 
management of multi application smart card schemes 
much more complex. The associated complexity and 
costs make application specific code in traditional card 
schemes almost infeasible. With the new technique the 
demand for this facility from smart card application pro- 
viders which has been there for some time can be met. 

Secondly, as direct consequence of protected ap- 
plication of specific programs in cards, a specific appli- 
cation can be implemented that is dedicated to load oth- 
er applications in the card. In this way, the applications 
once loaded in a card can be protected from the very 
application that loaded them. This protection gives par- 
ties involved in a multi application card scheme espe- 
cially the card issuing entity and the application provid- 
ing entities a basis for their business agreement. Being 
based on tangible things as the amount of storage need- 
ed on each card, the number of cards to be equipped 
and the duration of the application on the card instead 
of an abstract notion of "trust 0 and "good care" the ap- 
plication providers contract is easier to formulate than 
in traditionally implemented smart cards. Moreover, the 
card issuer and application provider do not need to 
share secret keys and protect this sharing with contrac- 
tual obligations and mutually agreed key transportation 
facilities. 

Thirdly, the application software if implemented 
based on the new technique has several benefits com- 
pared with prior art smart card operating systems: 



* A minimal exchange of data between a terminal and 
a card is needed to establish interoperability be- 
tween card and terminal, e.g. they support the same 
application(s). Values of data to be exchanged to 

5 this end can be structured as proposed in the draft 
international standard ISO 781 6-5; 

* To complete a transaction between card and termi- 
nal the minimal number of data exchanges as the- 
oretically inferred can actually be used, because the 

10 transaction is completed as a private computation, 
instead of the necessity to use a lengthy sequence 
of standard commands; 

* It allows controlled access to data without requiring 
an involved access path dictated by a directory and 

is file hierarchy shared by all applications as currently 
in use and proposed for standardisation; 

* It allows the development of the terminal and smart 
card application in tandem, which development 
process can be supported with computer software 

20 tools such as compilers and emulators. Design and 
implementation of card and terminal software can 
thus be lifted above the tedious and error prone as- 
sembly language coding currently required; 

* It allows standardization of equipment, both cards 
25 and terminals, using an abstract formalism to de- 
scribe the device capabilities which gives flexibility 
towards future developments, such as new features 
offered by card or terminal manufacturers. The 
standardized terminal capability could include an 

30 API. In contrast current standardization efforts in 
smart cards concentrates on prescribing fixed data 
contents of messages to provide identification val- 
ues to be interpreted in a way as determined by the 
standard, which leaves little room for new develop- 

35 ments. 

Finally, with the new technique implementors of 
smart card operating systems are given great freedom 
of designing optimal implementations of the card's op- 

40 erating system kernel and terminal operating system. 
Smart card hardware designers are given several op- 
tions to optimize chip silicon use with hardware support 
for basic operation included in the system kernel. Hard- 
ware cost reduction obtained starting with the special- 

45 ized design defined above can be greater than when 
based on improvements on general purpose single chip 
computers. 

The invention will now be described in detail with 
reference to some drawings which show an example of 
so the implementation of the general principles of the 
present invention. 

Figure 1 shows a prior art application design on 
smart cards based on an hierarchically organized 
55 collection of data elements; 

figure 2 presents a diagram of the communication 
flow between a portable processing unit and a sim- 
ilar structured processing unit in a format currently 
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accepted as standard; 

figure 3 presents a basic implementation of the 
present invention using the concept of interaction 
contexts in portable processing units, such as smart 
cards, and card terminals; 
figure 4 presents an example of a practical organi- 
zation of an execution context, highlighting different 
relationships between procedural descriptions con- 
* tained in the interaction context and data elements 
and library functions used while performing the pro- 
cedures; 

figure 5 shows an example of a flow diagram of pro- 
gram execution control and security context switch- 
es involved in performing the procedural description 
invoked by a communication primitive. 

The structure of data and files in prior art systems 
is depicted in figure 1. Basically there is a master file 1 
which is connected to several elementary files 3 and one 
or more dedicated files 2. Each dedicated file 2 may be 
connected to one or more further dedicated files 2 and 
to one or more elementary files 3. The prior art uses a 
tree-like hierarchy of directories and files. The number 
of subordinate levels in the prior art structure is in prin- 
ciple unlimited. The terminology used in figure 1 is taken 
from the international proposed ISO standard 7816-4. 
According to the standard format for communication 
flow between a portable data processing unit 5 and a 
similar structured data processing unit 4, as shown in 
figure 2, the communication comprises a set of pairs of 
blocks. The communication starts with a reset signal m<t> 
from the data processing unit 4. Such a reset signal may 
be outside the communication bandwidth such as gen- 
erated by power-on-logic in data processing unit 5. The 
portable data processing unit 5 responds with an answer 
to reset (ATR) signal ml possibly followed by contents. 
All subsequent pairs of blocks m2, m3, .... m(n-1), mn 
consist of blocks headed by a communication primitive 
(e.g. a command) followed by contents. 

Figure 3 shows the internal structure of two data 
processing units according to the invention which are 
communicating with each other by transmitting and re- 
ceiving data. The left data processing unit 4 may be, 
among others, a terminal and the right data processing 
unit may be, among others, a portable data processing 
unit, e.g. a smart card. However, the invention is also 
applicable to two portable data processing units able to 
communicate with each other by appropriate communi- 
cation means. 

Each of the data processing units 4, 5 comprises 
data communication means 7, 14 through which struc- 
tured blocks of data can be exchanged. Each of the data 
processing units 4, 5 comprises processing means 8, 
15, and memory means 9, 16. The memory means 9, 
16 could be any configuration of read-only memory 
(ROM), random access memory (RAM) and program- 
mable read-only memory such as electrically erasable 
programmable read-only memory (EEPROM). 



The memory means 9, 16 comprises an executive 
program 12,17, here indicated by "MAXOS". If the port- 
able data processing unit 5 is suitable for two or more 
applications the memory means 9, 16 comprises two or 
5 more application descriptions 13(1) ... 13(n), 18(1) ... 18 
(n). There are as many application descriptions as there 
are applications of the data processing unit concerned. 
Each application description is indicated by "CSA". The 
second application description 13(2), 18(2) has been 
shown on an enlarged scale in figure 3 to allow display 
of the contents of each application description. Each ap- 
plication description 13(i), 18(i) comprises at least one 
"interaction context" 11(1)... 11(m), 19(1)... 19(m). 
Each interaction context is indicated by "CTA". The first 
of these interaction contexts 11(1), 19(1) has been 
shown on an enlarged scale to allow display of their con- 
tents. Each interaction context contains: 

a set of commands specifying the communication 
primitives recognized by the interaction context and 
referencing appropriate procedures specified in a 
set of procedures; 
a set of data; 

a set of data references to date residing in other in- 
teraction contexts if any; 

a set of procedures that may be performed by the 
executive program 12, 17; 
a set of access conditions to the data elements; 
a set of external references referring to data ele- 
ments to be used in commands issued by the other 
data processing unit; 
optionally, developer specified other lists. 

Finally, the memory means 9,16 comprises a mem- 
ory element 21 , 20 that contains a reference to the "cur- 
rent CTA", i.e. the interaction context currently in force. 

The intention of several interaction contexts within 
one application description is to provide a functional 
separation in possible interactions between the data 
processing units 4, 5. This is especially relevant when 
the functional separation is also a separation in security 
conditions. An example may be a first interaction be- 
tween a smart card and a terminal to open, for instance, 
a door and a second interaction when programming 
doors that are allowed to be opened. The second inter- 
action needs a better security than the first interaction 
and is assigned its own interaction context. To obtain 
access to the interaction context is the first step in as- 
suring the security of the operations that may be exe- 
cuted within the interaction context. 

Figure 4 shows a practical approach to implemen- 
tation of the context mechanism displayed as a memory 
organization model which shows the relations between 
data elements, access conditions and procedures. The 
structure of figure 4 applies whenever there are two or 
more applications of the portable data processing unit 
5. If there is only one application the structure is strongly 
simplified, as will be explained later. In figure 4 the ref- 
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erence numbers of the data processing unit 5 are de- 
picted. However, the structure of figure 4 is likewise ap- 
plicable to the memory means 9 of the data processing 
unit 4. In figure 4 data element descriptions and proce- 
dure descriptions are optimally organized to reflect shar- s 
ing of program code and sharing of data between differ- 
ent interaction contexts (CTA's) which make up one ap- 
plication (CSA). 

The memory means 16 comprise data elements H 
(1)... H(7), executable code elements G(1)„. G(5) 
which are part of the operating system, and application 
descriptions 18(1), 1 8(2) (CSA1 , CSA2). In figure 4, da- 
ta and code which are internal to the operating system 
are left out. The number of data elements, executable 
code elements and application descriptions as present- 
ed in figure 4 is only given by way of example: the num- 
bers may vary as required in reality. 

Each application description 18(1), 18(2) is physi- 
cally present in the memory means. They provide a first 
bottom layer of abstraction to reflect memory use. Each 
application description 18(1), 18(2) consists of: 

a procedure library consisting of units of executable 
code F(1) ... F(4) that may refer to units of execut- 
able code of the operating system made available 
for this purpose, as indicated by arrows p(1 ) ... p(5); 
a list of data elements E(1) ... E(7) to be used by 
procedures within the interaction contexts 19(1) ... 
19(2) within the present application description 18. 
This data list comprises data access conditions and 
pointers q(1) ... q(7) to storage areas holding data 
elements; 

an interaction context list comprising a number of 
interaction context descriptions 19(1), 19(2). 

The number of elements within the procedure li- 
brary, the list of data elements and the interaction con- 
text list within the application description 1 8(1 ) as shown 
in figure 4 is for presentation purposes only. Of course, 
the number of elements may vary depending on the de- 
sired application. 

Interaction contexts 19(1), 19(2) are physically 
present in the memory means storing the application de- 
scription 18(1). Logically, the interaction contexts pro- 
vide a second layer of memory use control. The com- 
bined control provided by this second layer and the ap- 
plication description layer gives an effective implemen- 
tation of an execution context mechanism for portable 
data processing units, such as smart cards. Each inter- 
action context 19(1), 19(2) comprises: 

a list of procedural descriptions C(1) ... C(5). These 
procedure descriptions may refer to procedural de- 
scriptions in the procedure library within the appli- 
cation description 18 as indicated by example ar- 
rows s(1), s(2). Alternatively these procedural de- 
scriptions may refer to executable code elements G 
(1 ) ... G(5) provided by the operating system, as in- 



dicated by example arrow t(1 ). As a further alterna- 
tive these procedural descriptions may contain ex- 
plicit references to any data elements which are 
used by the procedure during execution and which 
are present in the data list of the application descrip- 
tion 18 concerned, as indicated by arrows r(1) ... r 
(6); 

a data list containing data elements B(1) ... B(5) ex- 
clusively available for use by the procedures in the 
interaction context concerned. Data elements are 
represented as references to the data list of the ap- 
plication description 18 concerned with associated 
access conditions to adhere to when accessing the 
actual data, as indicated by arrows u(1) ... u(5); 
an external interface list comprising communication 
primitives A(1) ... A(4) which are accepted as com- 
mands by the interaction contexts 1 9(1), 1 9(2) con- 
cerned. Each command within a communication 
primitive refers to a member of the procedural de- 
scriptions C(1) ... C(5) of the procedure list within 
the interaction context concerned, as indicated by 
arrows v(1) ... v(4). The commands when issued by 
the communicating device 4, may refer to elements 
in the data list of the application description by one 
or more addresses following the command. Each 
command may be accompanied by data elements 
as input to the command processing. The number 
of addresses as given here is by example only and 
is determined for each command as required in re- 
ality. 

Protection of data elements is provided for by the 
provision of access conditions. Any external command 
within a communication primitive A(1) ... A(4) can only 
address data elements referenced in the data list of the 
interaction context 19 concerned. Access is only al- 
lowed if the access conditions are met. These access 
conditions specify the type of access that is allowed for 
the command; such an access condition may be no ac- 
cess, read-only access, read-and-write access, and se- 
cret key use. Other access conditions may be applied 
too. For example, the command of communication prim- 
itive A(1 ) may have read-only access to data element B 
(2) through reference arrow w(2), while the command of 
communication primitive A(2) has read-and-write ac- 
cess to the same data element B(2) through reference 
arrow w(3). 

Procedural descriptions C(1) ... C(5) can refer to 
data elements in the data list of the application descrip- 
tion 18 concerned and no others. Again, access is only 
provided if the access condition is met. These access 
conditions also specify the type of access that is al- 
lowed: for instance, no access, read-only access, read- 
and-write access, and secret key use. Access condi- 
tions for different procedural descriptions within the 
same interaction context 19 may differ for the same ap- 
plication description data list element E(1) ... E(7), e.g. 
reference arrow r(1) may represent a read-only access 
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condition, whereas reference arrow r(2) may represent 
a read-and- write access condition. 

Access conditions are checked on the relevant lev- 
el, i.e. application description level or interaction context 
level and only once. An element B(1) ... B(5) of the data 
list within an interaction context 19(1), 19(2) refers di- 
rectly by arrow u(1) ... u(5) to the pointer of a data ele- 
ment in the data list of the application description 18(1) 
because the access conditions are already met in the 
data list element E(1) ... E(7) of the application descrip- 
tion 18(1). Procedural descriptions C(1)... C(5) within 
an interaction context 19(1), 19(2) which refer to data 
list elements within application description 18(1), how- 
ever, have to first meet the access condition associated 
with the data list elements E(1) ... E(7) within the appli- 
cation description 18(1). Any data elements or proce- 
dural description elements within the data lists of the ap- 
plication description 18(1 ) and its associated interaction 
contexts 1 9(1 ), 19(2) cannot be referred to by any other 
application description within the memory means 16. 
The executable code which constitutes the procedural 
description can only address data by indirection via the 
restricted set of data references associated with each 
of the procedural descriptions C(1) ... C(5). Using data 
elements described by B(1 ) ... B(5) the list of references 
is temporarily extended by the executive program with 
references to data element as obtained by evaluating 
addresses which are actually specified in the communi- 
cation message accepted as the command associated 
with the procedural description. Thus no other data can 
be accessed than explicitly specified, and only observ- 
ing specified conditions of use. In other words, the pre- 
ferred memory reference model of figure 4 as regards 
the application description with its associated interac- 
tion contexts provides an exclusive context for opera- 
tions within one single application of the data processing 
unit 5. Data elements H(1) ... H(7) are stored in the 
memory means 16 common to all applications but con- 
tain data for exclusive use within the context of applica- 
tion description 18(1), such exclusivity is guaranteed by 
the executive program in allowing extstance of a single 
pointer to each storage location such as q(1) from E(1) 
to H(2). Only the code elements G(1) ... G(5) may be 
referred to by any of the application descriptions 18(1)... 
stored within the memory means 16. These last refer- 
ences of other application description than application 
description 18(1 ) to the common codes G(1) ... G(5) are 
not explicitly indicated in figure 4. However, any person 
skilled in the art can easily extend the structure of figure 
4 to two or more application descriptions 18(1), 18 
(2),... . 

After having explained how data elements may be 
protected by the use of access conditions of different 
kinds, now, memory management provisions will be ex- 
plained. For memory management, it is desirable that 
alterable data (data elements) and not alterable data 
(operating system code) can be managed by the oper- 
ating system separately. The memory reference model 



as shown in figure 4 provides a separation of code and 
data elements within the memory means 16 which are 
referred to by pointers q(1 ) ... q(7), p(1 ) ... p(5) from the 
data list and the procedure library, respectively, within 

5 the application description 18 concerned. Data list ele- 
ments within each interaction context 19(1), 19(2) only 
contain references to these pointers and no direct ref- 
erences to the codes G(1) ... G(5), and the data ele- 
ments H(1) ... H(7) within the memory means 16. The 

10 data list of the application description 1 8 concerned pro- 
vides the level of indirection required by the operating 
system to perform memory management. 

Code duplication is avoided by providing common 
code libraries on two levels: "command bodies" like pro- 

is cedural description C(3) which refer to code element F 
(2) in the procedure library in application description 18 
(1 ) in order to share common codes among different in- 
teraction contexts. However, the body of procedural de- 
scription C(3) also refers directly to a code G(3) stored 

20 in the memory means 1 6 and provided by the operating 
system. All units of executable code G(1) ... G(5) pro- 
vided by the operating system are implemented for ef- 
ficient execution. 

Fundamentally, the memory structure according to 

25 figure 4 is also applicable in situations where only one 
application of the data processing unit 5 is provided for. 
In that case the only application description 18(1) may 
even coincide with one interaction context 19(1), which 
interaction context then contains at least the following 

30 coherent data structure: 

a. a set of basic communication primitives A(1) ... 
which are accepted whenever the data processing 
unit 5 communicates with a similar unit 4, said prim- 

35 itives at least including a primitive used to selective- 
ly enter one of the said at least one interaction con- 
texts; 

b. a set of procedural descriptions C(1) ... defining 
the actions to be performed in response to each of 

40 the accepted communication primitives A(1) .... at 
least comprising a first procedural description to be 
performed upon activating the interaction context, 
and a last procedural description to be performed 
immediately before deactivating the context; 

45 c. a, possibly empty, set of data elements H(1) ... 
either permanently stored or computed, which are 
available for use when procedures as defined in the 
procedural descriptions C(1) ... are performed; 

d. a, possibly empty, set of references to data ele- 
so ments, which references are associated to the pro- 
cedural descriptions C(1) .... said data elements are 
also accessible to possibly further interaction con- 
texts and are available for use when procedures as 
defined in the procedural descriptions C(1) ... are 

55 performed; 

e. a, possibly empty, data list comprising a list of 
references to data elements which are available for 
explicit reference as part of a communication prim- 
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itive to be used by the procedural description asso- 
ciated with the communication primitive; 

f . a set of access conditions associated to the data 
elements which are referenced in association to the 
procedural descriptions; $ 

g. a set of access conditions associated to the list 
of data references B(1) ... in the data list. 

If there is only one application provided for the data 
processing unit 5 and there are at least two interaction 
contexts 19(1), 19(2) each application description com- 
prises: 

a. a data list comprising references E(1) ... to data 
elements, which references may be accessible to 
two or more interaction contexts 19(1) ... and may 
be extended by additional data elements; 

b. a further set of access conditions associated to 
said references E(1 ) ... or to said additional data el- 
ements and defining restrictions of use. 

The set of procedural descriptions in each of the two 
or more interaction context descriptions also contains 
an additional last procedural description to be per- 
formed immediately before deactivating the context. 

Figure 5 represents the flow of control in the exec- 
utive program defined above by "MAXOS" (12,17). 

After powering the system the software starts with 
processing a reset code in step 30. In step 31 the kernel 
operations security level of the data processing unit is 
entered. The access conditions describing this level are 
stored in an unmodifiable part of memory, e.g. ROM or 
hardware logic. In step 32 the non-volatile memory is 
checked for consistency and any modifications which 
might have been left unfinished by sudden power down, 
e.g. by extraction of a smart card, are cancelled. Non- 
volatile memory consistency check only involves exam- 
ining state information stored in memory and computing 
check sums. The content of memory, if accessed at all, 
is only used to compute check sums. Thus, the consist- 
ency check is a safe operation. The exact nature of the 
consistency check facilities depends on details of hard- 
ware within the data processing unit and non-volatile 
memory modification routines which are to a wide extent 
irrelevant to the specified security architecture. After the 
general memory consistency check the pre-computed 
levels of the security context stored in the memory are 
verified. Finally, the random access memory of the data 
processing unit is initiated. 

In step 33, if the executing environment is thus de- 
clared safe, the secure application security level of the 
data processing unit is entered. In this level any access 
to memory pertaining the kernel operations is blocked. 
Access to application data and description from this lev- 
el is exclusively provided through routines in the kernel 
which maintain state information on ongoing memory 
operations. 

Upon first entry after reset, in step 34 application 



data element descriptors are used to check consistency 
of stored data with the descriptor and memory is 
changed if in a state inconsistent with the attribute as 
described. An answer to reset (ATR) message is com- 
posed from application identifiers stored in the applica- 
tion descriptors and completed with a transaction 
number computed to be unpredictable by the receiving 
other data processing unit 4. Internal to the data 
processing unit a terminal command is generated to ac- 
tivate a default interaction context. Directly after the ATR 
message is sent to the other data processing unit 4 this 
internal context activation command is executed to pro- 
vide an interaction context for subsequent commands. 
The ATR message clearly indicates the readiness of the 
data processing unit 5 to accept further commands. The 
default interaction context can be designed as part of a 
"smart card holder application" which is present as one 
standard application in all multi-application smart cards. 
In this specific application context the user, i.e. the smart 
card holder, can review his personal data or open any 
of the other applications on the card. 

In step 35, as result of the context activation com- 
mand, the interaction context (CTA) security level is en- 
tered for the standard smart card holder CTA. 

After an application has been activated completely 
it is ready to receive commands from the other data 
processing unit 4. Further processing depends on the 
command received: a command to activate an applica- 
tion is handled different than a command which is to be 
executed. Therefore, in step 38, after having estab- 
lished that a communication primitive is received in step 
36 and is established to be acceptable in step 37, it is 
tested whether a new application has to be activated. If 
not, step 39 is entered in which the command is checked 
to determine whether it is allowed and the input data can 
be accepted. These checks are performed for a com- 
mand only if specified in the application descriptor. Also 
a decryption of input data may be carried out in step 39. 

If the test succeeds the "data access protection lev- 
el" is entered, step 40. On this level, the highest security 
level, routines may be executed which are coded by ap- 
plication providers, step 41 . Such routines are stored in 
the application descriptor and function as an application 
specific reaction to a specific command issued by the 
other data processing unit 4. This security level con- 
strains memory access to a subset specifically defined 
for the command being executed. 

After carrying out the command with the submitted 
input data in step 41 , the data access protection level is 
left, step 42. 

Output data and (cryptographic) proof of command 
completion is generated in step 43. After step 43 the pro- 
gram waits for new communication primitives, step 36. 

If no special command routine is defined and the 
command can be executed by procedures consisting 
solely of operating system functions the data access 
protection level (step 40) is not entered, and the com- 
mand will be performed on the interaction context secu- 
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rity level directly as the operating system routines are 
designed not to violate any data protection. 

If, in step 38, it is established that nonewapplication 
is to be activated the program proceeds with step 44 in 
which a context de-activation procedure is performed. 
In step 45 the current application specific security level 
is left and, in step 46, within the security level of the ex- 
ecutive program "MAXOS" the data accompanying the 
command are checked. 

If the command is allowed by proper authentication 
as specified for the requested application a new appli- 
cation specific CTA security level is entered, step 47. 
This level restricts access to data pertaining to the newly 
opened application. 

The data processing unit 5 produces data in re- 
sponse to a context activation command by executing 
an initialization instruction as defined in the procedure 
list, step 48. If such an application provider coded rou- 
tine is present the data access protection level is en- 
tered in step 49. The context activation procedure is per- 
formed in step 50. In step 51 the data access protection 
level is left and the response is communicated to the 
other data processing unit 4 and the data processing 
unit 4 itself is ready to receive a new command after 
step 43, specified above. 

After having described the figures 1 to 5, now some 
general remarks to the data exchange system according 
to the invention are made. 

The codes in the procedure library within each ap- 
plication description 18(1), 18(2) may be enhanced by 
including a specification of the use of their operational 
parameters into classes relating to attributes pertaining 
to data elements which can be passed as actual value 
in a computation, which computation only proceeds if 
the data attributes and parameter classes match. This 
provides one way to verify access conditions both to da- 
ta elements and to functions. Comparing properly en- 
coded bit maps of data attributes and parameter classes 
respectively may provide an efficient implementation for 
this additional technique. 

The executive program 12, 17 may comprise a ref- 
erence to an interaction context which is used to initial- 
ize the current interaction context in the memory ele- 
ment 20 storing a reference to the interaction context 
currently being in force. By this measure it is possible to 
carry out a final action after a detection of an internal 
inconsistency in a recovery to a normal state of opera- 
tion or whenever the executive program 1 2, 17 is active 
and no explicit interaction context has been specified by 
a communication primitive received from the other data 
processing unit 5. This default interaction context may 
well be one such context contained in the cardholder 
application as described above. 

Additionally, the memory means 9, 16 may com- 
prise an interaction context 11,19 dedicated to comprise 
personal identification numbers (PIN's) and the execu- 
tive program 12, 17 is arranged to verify personal iden- 
tification numbers supplied by a user of the data ex- 



change system. Several such personal identification 
numbers, passwords, may be used. One such password 
may be used to protect use of the device in transactions 
where privacy sensitive data can be revealed. A second 

s password may be used to protect transactions where 
data representing a value payable by the password 
holder is communicated. A third password may be used 
to protect transactions where operations are performed 
deemed critical to the security of the application such as 

10 modes of protection being called upon as specified with- 
in each of the interaction contexts 11,19 that may re- 
quire it. Further passwords may be provided for. This 
PIN management interaction context may well be one 
such context contained in the card-holder application as 

75 described above. 

Each application description 13, 18 may comprise 
a list of numeric values which is constructed to provide 
identifiers for all interaction contexts 11, 19 and each 
application description 13, 18 may comprise at least a 

20 first numeric value indicating an application type, a sec- 
ond numeric value indicating a unique identification of 
the entity providing the application, a third numeric value 
indicating the nature of the application description 13, 
18 and further numbers each uniquely referring to one 

2$ interaction context 11,19. The first two numbers may be 
assigned according to rules well established in the 
trade, whereas the remaining numbers may be chosen 
by the application providing entity as deemed appropri- 
ate. Especially it may assign numeric values to distin- 

30 guish between different version of the implementation 
or to identify the generation of the set of cryptographic 
keys employed by the application in its cryptographic 
computations. Additionally, the device may include in 
the answer to reset message a list for each of the inter- 

35 action contexts 11, 19 contained in its memory means 
an identification number composed of the unique iden- 
tification values stored with the interaction context. The 
first element in the list of interaction context identifica- 
tion numbers may be an identification for the default 

40 context. 

The data communication means 7, 14 are prefera- 
bly arranged to structure data exchange in blocks of da- 
ta. These blocks of data comprise at least two parts, a 
first part being data qualified as operational in that it is 

4$ used to influence the nature of the operations performed 
by a command as indicated by a communication primi- 
tive or data resulting from operations carried out. A sec- 
ond part will be qualified as security in that it is used to 
determine that appropriateness of performing an oper- 

50 ation or of the acceptability of data within the operational 
part to be used in the operation or to prove completion 
of the operation or correctness of the revealed data. 

When the data is structured in this way the execu- 
tive program 17 may be arranged to perform, upon ac- 

55 cepting a communication primitive to perform opera- 
tions specified in the current interaction context 20, 21 , 
each operation as part of a predetermined and fixed se- 
quence of actions, each of which is specified separately 
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as part of a procedure description rule associated to the 
accepted communication primitive. A first action may be 
specified as a function to authorize the use of the com- 
munication primitive at this point in the sequence of 
communications. A second action may be specified as 
a function to decrypt the operational data or any part of 
it, whereas a third action may be specified as the oper- 
ational procedure proper. A fourth part may be specified 
to encrypt any operational data which results from the 
operations performed and a fifth action may be specified 
as a function to compute a proof of completion of the 
performed action or of correctness of the resulting data 
or to be used in security computations in the receiving 
data processing unit. These actions are reflected by the 
flow diagram of figure 5. 

Additionally, the data processing unit 5 may include 
in its answer to reset message a number chosen to be 
unpredictable in value by the receiving data processing 
unit 4, which can serve as the basis for cryptographic 
computations. Such a number may be designated as the 
"card transaction number". 

There will be provided for one communication prim- 
itive assigned a specified value which will always be in- 
terpreted as a request to enter a new interaction context 
11,19. This communication primitive may be designated 
as the "activation command". The data accompanying 
the activation command sufficiently specifies the con- 
text to be activated possibly by referring to the identifi- 
cation numbers communicated as part of the answer to 
reset message. The actions performed in responding to 
the activation command are firstly described by the pro- 
cedural description contained in the context accepting 
the primitive designated as for deactivation and second- 
ly described in the procedural description designated for 
activation contained in the context specified as to be en- 
tered. 

Preferably the communication primitive used to en- 
ter a specified interaction context 11,19 comprises nu- 
meric values to be used in security calculations in sub- 
sequent communications. A first random value may be 
generated by one of the processing units 4, 5 and a sec- 
ond value may serve to identify that one processing unit. 
This identification might be the result of computations, 
which are such that the resulting value sufficiently iden- 
tifies the device and the state of its memory as required 
by computations or other actions which might be done 
in subsequent exchanges of data in the interaction con- 
text 11, 19 to be activated. Said second value may be 
designated as "terminal identification 0 . 

Additionally, the activation command gives as part 
of the resulting data a numeric value serving to identify 
the particular responding data processing unit sufficient- 
ly as required by computations or other actions which 
might be done in subsequent exchanges of data in the 
context just being activated, which number may be des- 
ignated as "smart card identification". 

Besides the smart card identification number may 
be computed using cryptographic functions from data 



stored in the data processing unit 5 or from the data re- 
ceived as part of the activation command in such a way 
that the number varies in unpredictable manner when 
computed in response to activation commands received 

s from initiating devices with differing terminal identifica- 
tion numbers; a smart card identification thus computed 
can be designated as the "smart card pseudonym". 
Moreover, before performing the actions described in 
the procedural description of the activation procedure of 

10 a context to be entered the executive program may per- 
form a cryptographic computation specified as part of 
the procedural description in that context designated to 
be performed upon activation to determine whether the 
context may be activated. The computations may in- 

1$ volve use of the smart card transaction identification, 
terminal transaction identification and terminal identifi- 
cation and other values stored in the memory means. 

As an alte rnative to such specific computations sup- 
ported with specific data in performing commands, com- 

20 mands with bitfield specification of referenced data ele- 
ments may be used. Then, each communication primi- 
tive is composed of two or more numeric values, a first 
value being used to refer to a procedural description of 
an action associated to the communication primitive, a 

25 second value being composed of a fixed number of bi- 
nary values each of which is interpreted by the executive 
program 1 2, 1 7 as a reference to a single data element. 
This data element is specified in the list of external data 
references in the interaction context 11,19 concerned, 

30 each data element in the list being specified by the pres- 
ence of a binary value of one of the binary numbers in 
a corresponding position in the list of binary values. This 
second value may be designated as the "operand ad- 
dresses". Each of the data elements which are so spee- 
ds if ied are made available by the operating executive pro- 
gram 12, 17 to be used in the responding action in a 
manner as may be described in the procedural descrip- 
tion of that action. 

As an alternative to specific computations with spe- 

40 cif ic date and commands with bitfield specification of ref- 
erenced data elements a command format with data 
match specification of data may be applied. In that case, 
each communication primitive is composed of two or 
more numeric values, a first value being used to refer to 

45 a procedural description of an action associated to the 
communication primitive, a second value being used to 
determine which of the data elements available for ex- 
ternal reference in an active interaction context 12, 19 
will be used while performing responding actions in such 

so a way that any data element is selected if it contains a 
value that matches said second value. This second val- 
ue may be designated as the "operand tag specifier". 
Additionally, the interaction context 11, 19 may contain 
a procedural description indicating in what way an op- 

55 erand tag specifier given as part of a command is to be 
compared with data contained in any of the data ele- 
ments available for external reference in that context, 
which procedural description is performed to select the 
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intended data elements before the procedural descrip- 
tion is performed specifying the command actions prop- 
er. 

As a further alternative a command format with bit- 
field specification of command interpretation may be 
used. Then each communication primitive is composed 
of two or more numeric values, a first value being used 
to refer to a procedural description of an action associ- 
ated to the communication primitive, a second value be- 
ing composed of a number of binary values which are 
assigned specific meaning by the executive program 12, 
17 to be used in interpreting data formats in the com- 
munication primitive and in performing responding ac- 
tions. Here the second value may be designated as 
"command modifier". The values are recognized for 
their assigned meaning by all units equipped with this 
additional technique. 

In case the latter alternative is applied the command 
modifier may include a binary value which determines 
whether a third part of the command is to be used as 
operand address or as operand tag specifier. However, 
the command modifier may, as an alternative, include a 
binary value which determines whether the operation 
performed as response to the command will use data 
as one data element or is composed of a concatenation 
of data elements one to be processed in conjunction 
with each data element specified as part of the com- 
mand value using operand addresses or the operand 
tag specifier. Alternatively, the command modifier may 
include a binary value which determines whether data 
provided with the command is encoded using the tag- 
length-value method to discriminate successive con- 
catenated data elements. 

A further option is that the command modifier may 
include a binary value which determines whether per- 
forming the action implied by the command will actually 
lead to effective change of data stored in the data 
processing unit 5 (smart card) or actually result in data 
computed by the data processing unit 5, or that the com- 
mand result is data reflecting the state of the unit with 
regard to the acceptability of the command, the data ac- 
companying it, the size of the data which could result 
from computations or other sundry attributes. 

In short, the new technique introduced above espe- 
cially suitable for implementation in smart cards is the 
concept of a separate execution environment. In this ap- 
proach the processing means and other resources in a 
computer are shared between different applications as 
if the application was the only user of the computer. 
Building on this new technique in smart card implemen- 
tations in addition a mechanism is provided to define 
multiple access conditions for data shared by a number 
of related applications. A second technique supported 
by the separate execution environments and introduced 
above is the possibility to define the functional meaning 
of commands in each environment to obtain a minimum 
number of commands in each interaction between two 
similar data processing units 4, 5 within a data exchange 



system. Finally it is possible with the new technique for 
names referring to stored data elements to be assigned 
within each context separately. The reference to stored 
data elements as part of a command received from one 
s of the data processing units 4, 5 can thus be made very 
efficient: due to the very small number of data elements 
and small number of distinct operations that is used in 
today's smart card practice in each environment sepa- 
rately only a few bits are needed to encode the name 
10 and instruction space. In a similar fashion access con- 
ditions, methods of verification thereof and cryptograph- 
ic operations available to that end in actual smart cards 
will be very restricted in number and they can be ex- 
pressed very efficiently in the two tier hierarchy of inter- 
is action context descriptions 1 9(1 ) .. . enclosed in applica- 
tion description 18. 
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Claims 



1. Data exchange . system comprising at least one 
portable data processing unit (5) comprising data 
communication means (14), processing means (15) 
and memory means (16), the later comprising an 
25 executive program (17) characterized in that the 
memory means (16) further comprises at least one 
interaction context (19(1) ... 19(m)) containing the 
following coherent data structure: 



a. a set of basic communication primitives (A 
(1) ...) which are accepted whenever the data 
processing unit (5) communicates with a similar 
unit (4), said primitives at least including a prim- 
itive used to selectively enter one of the said 
interaction contexts (19(1) ...); 

b. a set of procedural descriptions (C(1 ) ...) de- 
fining the actions to be performed in response 
to each of the accepted communication primi- 
tives (A(1 ) ...), at least comprising a first proce- 
dural description to be performed upon activat- 
ing the interaction context, and a last procedur- 
al description to be performed immediately be- 
fore deactivating the context; 

c. a, possibly empty, set of data elements (H 
(1) ...) either permanently stored or computed, 
which are available for use when procedures 
as defined in the procedural descriptions (C 
(1) ...)are performed; 

d. a, possibly empty, set of references to data 
elements, which references are associated to 
the procedural descriptions (C(1) ...), said data 
elements are also accessible to possibly further 
interaction contexts and are available for use 
when procedures as defined in the procedural 
descriptions (C(1) ...) are performed; 

e. a, possibly empty, data list comprising a list 
of references (B(1) ...) to data elements which 
are available for explicit reference as part of a 
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communication primitive (A(1 ) .. .) to be used by 
the procedural description (C(1) ...) associated 
with the communication primitive; 

f . a set of access conditions associated to the 
data elements which are referenced in associ- $ 
ation to the procedural descriptions (C(1) ...); 

g. a set of access conditions associated to the 
list of data references (B(1) ...) in the data list. 

Data exchange system according to claim 1 char- 10 
acterized in that the memory means (16) further 
comprises at least two interaction contexts (1 9(1) ... 
19(m)), at least one application description (18 
(1) ....) and a memory element (20) storing a refer- 
ence to the interaction context currently being in is 
force, each application description comprising: 

a. a data list comprising references (E(1 ) .) to 
data elements, which references may be ac- 
cessible to two or more interaction contexts (19 20 
(1 ) ...) and may be extended by additional data 
elements; 

b. a further set of access conditions associated 
to said references (E(1 ) ...) or to said additional 
data elements and defining restrictions of use. 2$ 

Data exchange system according to claim 2 char- 
acterized in that each application description (18 
(1) ...) also comprises a procedure library compris- 
ing units of executable code (F(1) ...) which can be 30 
used by procedural descriptions (C(1) ...) of each 
interaction context associated to each of said appli- 
cation descriptions (18(1) ...). 

Data exchange system according to claim 2 or 3 35 
characterized in that the memory means comprises 
at least two application descriptions (18(1) ....) and 
units of executable code (G(1) ...) which can be 
used by procedural descriptions (C(1) ...) of each 
interaction context (19(1) ...) within each applica- *o 
tion description (18(1) ...)or by each unit of execut- 
able code (F(1 ) ...) of each procedure library within 
each application description (18(1) ...). 

Data exchange system according to any of the 45 
claims 3 or 4 characterized in that the units of exe- 
cutable code in the procedure library are enhanced 
by including a specification of the use of their oper- 
ational parameters into classes relating to attributes 
pertaining to data elements which can be passed so 
as actual value in a computation, which computa- 
tion only proceeds if the data attributes and param- 
eter classes match. 

Data exchange system according to any of the ss 
claims 2 to 5 characterized in that the executive pro- 
gram (17) comprises a reference to a default inter- 
action context which is used to initialise the memory 



element (20) storing a reference to the interaction 
context currently being in force, in order to carry out 
a final action after a detection of an internal incon- 
sistency in a recovery to a normal state of operation 
or whenever the executive program (17) is active 
and no explicit interaction context has been speci- 
fied by a communication primitive received from an 
opposite data processing unit (4). 

7. Data exchange system according to any of the pre- 
ceding claims characterized in that the memory 
means (16) comprises an interaction context dedi- 
cated to comprise Personal Identification Numbers 
and that the executive program (17) is arranged to 
verify Personal Identification Numbers supplied by 
a user of the data exchange system. 

8. Data exchange system according to any of the 
claims 2 to 7 characterized in that each application 
description (18(1) ...) comprises a list of numeric 
values which is constructed to provide identifiers for 
all interaction contexts (19(1) ...) and comprises at 
least a first numeric value indicating an application 
type, a second numeric value indicating a unique 
identification of the entity providing the application, 
a third numeric value indicating the nature of the ap- 
plication description (18(1) ...) and further numbers 
each uniquely referring to one interaction context 
(19(1) ...) associated with the application descrip- 
tion. 

9. Data exchange system according to any of the pre- 
ceding claims characterized in that the data com- 
munication means (14) is arranged to structure data 
exchange in blocks of data comprising at least two 
parts, a first part being data qualified as operational 
in that it is used to influence the nature of the oper- 
ations performed by a command as indicated by a 
communication primitive or data resulting from op- 
erations carried out, a second part being qualified 
as security in that it is used to determine the appro- 
priateness of performing an operation or of the ac- 
ceptability of data within the operational part, to be 
used in the operation or to prove completion of the 
operation or correctness of the resulting data. 

10. Data exchange system according to claim 9 char- 
acterized in that the executive program (17) is ar- 
ranged to perform, upon accepting a communica- 
tion primitive to perform operations specified in the 
current interaction context (19(1) ...), each opera- 
tion as part of a predetermined and fixed sequence 
of actions each of which is specified separately as 
part of a procedural description associated to the 
accepted communication primitive, which actions 
comprise at least the following actions: 

a. authorization of the use of the communica- 
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tion primitive; 

b. decryption of operational data or any part of 
it; 

c. performing a command with any input data; 

d. encryption of any operational data resulting 
from any operation performed; 

e. computation of a proof of completion of any 
performed action or of correctness of the result- 
ing data to be used in security computations. 

1 1 . Data exchange system according to any of the pre- 
ceding claims characterized in that the data 
processing unit (5) generates a random transaction 
number upon initializing data transfer, which serves 
as basis for cryptographic computations. 

12. Data exchange system according to any of the pre- 
ceding claims characterized in that one communi- 
cation primitive is assigned a specified value which 
will always be interpreted as a request to enter a 
new interaction context (19(1) ...). 

1 3. Data exchange system according to any of the pre- 
ceding claims characterized in that it comprises a 
further data processing unit (4) comprising the 
samfc elements as the data processing unit (4) 
which might optionally contain in its memory an ap- 
plication programmers interface (1 0) which consists 
of program code designed to allow additional com- 
puter programs to be implemented to give users 
control over the sequence of exchanged communi- 
cation primitives or to influence the data transferred 
in them or to learn or further process the data re- 
ceived in the exchange. 

14. Data exchange system according to claim 13 char- 
acterized in that the primitive used to enter a spec- 
ified interaction context (19(1)...) comprises nu- 
meric values to be used in security calculations in 
subsequent communications, a first random value 
generated by one of the processing units and a sec- 
ond value serving to identify said one processing 
unit. 

1 5. Data exchange system according to claim 1 3 char- 
acterized in that each communication primitive is 
composed of two or more numeric values, a first val- 
ue being used to refer to a procedural description 
of an action associated to the communication prim- 
itive, a second value being composed of a fixed 
number of binary values each of which is interpreted 
by the executive program (1 2; 1 7) as a reference to 
a single data element. 

16. Data exchange system according to claim 1 3 char- 
acterized in that each communication primitive is 
composed of two or more numeric values, a first val- 
ue being used to refer to a procedural description 



of an action associated to the communication prim- 
itive, a second value being used to determine which 
of the data elements available for external refer- 
ence in an active interaction context (19(1) ...) will 
5 be used while performing responding actions in 
such a way that any data element is selected if it 
contains a value that matches said second value. 

17. Data exchange system according to claim 1 3 char- 
10 acterized in that each communication primitive is 
composed of two or more numeric value's, a first val- 
ue being used to refer to a procedural description 
of an action associated to the communication prim- 
itive, a second value being composed of a number 
is of binary values which are assigned specific mean- 
ings by the executive program (12, 17) to be used 
in interpreting data formats in the communication 
primitive and in performing responding actions. 

20 

Patentanspruche 

1. Datenaustauschsystem mit wenigstens einer trag- 
baren Datenverarbeitungseinheit (5), welche eine 
25 Datenkommunikationseinrichtung (14), eine Verar- 
beitungseinrichtung (15) sowie eine Speicherein- 
richtung (16) umfaBt, wobei die letztere ein Ausfuh- 
rungsprogramm (17) umfaGt, dadurch gekenn- 
zeichnet, 

30 daG die Speichereinrichtung (1 6) ferner wenigstens 
einen Interaktionskontext (19(1) ... 19(m)) umfaGt, 
weicher die folgende koharente Datenstruktur be- 
inhaltet; 

35 a. einen Satz von Basis-Kommunikations- 

grundelementen (A(11 ...), die immer dann ak- 
zeptiert werden, wenn die Datenverarbeitungs- 
einheit (5) mit einer entsprechenden Einheit (4) 
kommuniziert, wobei die Grundelemente zu- 

40 mindest ein Grundelement umfassen, das dazu 

verwendet wird, selektiv in einen der Interakti- 
onskontexte (19(1) ...) einzusteigen; 

b. einen Satz von Prozedurbeschreibungen (C 
(1) ...), die die in Antwort auf jedes der akzep- 

45 tierten Kommunikationsgrundelemente (A 

(1).„) durchzufOhrenden Aktionen definieren 
und zumindest eine erste Prozedurbeschrei- 
bung umfassen, die bei Aktivierung des Inter- 
aktionskontextes durchzuf uhren ist, sowie eine 

so letzte Prozedurbeschreibung, die unmittelbar 

vor Deaktivierung des Kontextes durchzufuh- 
ren ist; 

c. einen moglicherweise leeren Satz von ent- 
weder permanent gespeicherten Oder berech- 

55 neten Datenelementen (11(1) ...). die zur Ver- 

wendung verfugbar sind, wenn Prozeduren, 
wie sie in den Prozedurbeschreibungen (C 
(1) ...) definiert sind, durchgefuhrt werden; 
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d. einen moglicherweise leeren Satz von Ver- 
weisen auf Datenelemente, welche Verweise 
den Prozedurbeschreibungen (C(1)...) zuge- 
ordnet sind, wobei die Datenelemente auch 
moglichen weiteren Interaktionskontexten zu- s 
ganglich sind und zur Verwendung verfugbar 
sind, wenn Prozeduren, wie sie in den Proze- 
durbeschreibungen (C(1)...) definiert sind, 
durchgefuhrt werden; 

e. eine moglicherweise leere Datenliste mit ei- 10 
ner Liste von Verweisen (B(1 ) ...) auf Datenele- 
mente, die zum expliziten Verweis als Teil eines 
Kommunikationsgrundelements (A(1)...) ver- 
fugbar sind, um durch die dem Kommunikati- 
onsgrundelement zugeordnete Prozedurbe- 1$ 
schreibung (C(1) ...) verwendet zu werden; 

f. einen Satz von Zugriffsbedingungen, die den 
Datenelementen zugeordnet sind, auf welche 
im Zusammenhang mit den Prozedurbeschrei- 
bungen (C(1) ...) verwiesen wird; 20 

g. einen Satz von Zugriffsbedingungen, dieder 
Liste von Datenverweisen (B(1) ...) in der Da- 
tenliste zugeordnet sind. 

Datenaustauschsystem nach Anspruch 1 , 2$ 
dadurch gckennzeichnet, daB die Speichereinrich- 
tung (16) ferner mindestens zwei Interaktionskon- 
texte (19(1)... 19 (m)), mindestens eine Anwen- 
dungsbeschreibung (18(1)...) sowie ein Speicher- 
element (20) umfaBt, das einen Verweis auf den In- 30 
teraktionskontext speichert, der momentan in Kraft 
ist, wobei jede Anwendungsbeschreibung umfaBt: 

a. eine Datenliste mit Verweisen (E(1) ...) auf 
Datenelemente, welche Verweise zwei Oder 35 
mehr Interaktionskontexten (19(1) ...) zugang- 

lich sind und durch zusatzliche Datenelemente 
erweitert sein konnen; 

b. einen weiteren Satz von Zugriffsbedingun- 
gen, die den Verweisen (E(1) ...) oder den zu- 40 
satzlichen Datenelementen zugeordnet sind 
und Nutzungsbeschrankungen festlegen. 

Datenaustauschsystem nach Anspruch 2, 
dadurch gekennzeichnet, daB jede Anwendungs- 4& 
beschreibung (18(1) ...) auBerdem eine Prozedur- 
bibliothekmit ausfuhrbaren Codeeinheiten (F(1) ..,) 
umfaBt, welche durch Prozedurbeschreibungen (C 
(1) ...) jedes Interaktionskontextes verwendet wer- 
den konnen, der jeder der Anwendungsbeschrei- so 
bungen (18(1) ...) zugeordnet ist. 

Datenaustauschsystem nach Anspruch 2 oder 3, 
dadurch gekennzeichnet, daB die Speichereinrich- 
tung mindestens zwei Anwendungsbeschreibun- 55 
gen (18(1) ...) und ausfOhrbare Codeeinheiten (G 
(1) ...) umfaBt, welche durch Prozedurbeschreibun- 
gen (C(1) ...) jedes Interaktionskontextes (19(1) ...) 



innerhalb jeder Anwendungsbeschreibung (18 
(1) ...) oder durch jede ausfOhrbare Codeeinheit (F 
(1 ) ...) jeder Prozedurbibliothek innerhalb jeder An- 
wendungsbeschreibung (18(1) ...) verwendet wer- 
den konnen. 

5. Datenaustauschsystem nach einem der Anspruche 
3 oder 4, dadurch gekennzeichnet, daB die ausfuhr- 
baren Codeeinheiten in der Prozedurbibliothek da- 
durch vergroBert sind, daB eine Spezifikation der 
Verwendung ihrerOperationsparameter in Klassen 
eingef ugt ist, welche sich auf Attribute beziehen, die 
Datenelemente betreffen, welche als tatsachlicher 
Wert in einer Berechnung genommen werden kon- 
nen, welche Berechnung nur dann fortschreitet, 
wenn die Datenattribute und die Parameterklassen 
zueinander passen. 

6. Datenaustauschsystem nach einem der Anspruche 
2 bis 5, dadurch gekennzeichnet, daB das Ausfuh- 
rungsprogramm (17) einen Verweis auf einen Stan- 
dard interaktionskontext umfaBt, welcher dazu ver- 
wendet wird, das Speicherelement (20) zu initiali- 
sieren, das einen Verweis auf den momentan in 
Kraft befindlichen Interaktionskontext speichert, um 
eine Endaktion nach einer Erfassung einer internen 
Inkonsistenz bei einer Wiederaufnahme eines nor- 
malen Operationszustands durchzufuhren oder 
wann immer das Ausfuhrungsprogramm (17) aktiv 
ist und kein expliziter Interaktionskontext durch ein 
von einer gegenuberliegenden Datenverarbei- 
tungseinheit (4) erhaltenes Kommunikationsgrund- 
element spezifiziert worden ist. 

7. Datenaustauschsystem nach einem der vorherge- 
henden Anspruche, 

dadurch gekennzeichnet, daB die Speichereinrich- 
tung (16) einen Interaktionskontext umfaBt, dessen 
Zweck es ist, personliche Identifizierungsnummern 
zu umfassen, und daB das Ausfuhrungsprogramm 
(17) dazu ausgelegt ist, von einem Benutzer des 
Datenaustauschsystems gelieferte personliche 
Identifizierungsnummern zu verifizieren. 

8. Datenaustauschsystem nach einem der Anspruche 
2 bis 7, dadurch gekennzeichnet, daB jede Anwen- 
dungsbeschreibung (18(1) ...) eine Liste von nume- 
rischen Werten umfaBt, die so aufgebaut ist, daB 
sie Bezeichner fur alle Interaktionskontexte (19 
(1) ...) bereitstelit, und zumindest einen ersten nu- 
merischen Wert umfaBt, welcher einen Anwen- 
dungstyp angibt, einen zweiten numerischen Wert, 
welcher eine ausschlieBliche Bezeichnung des Be- 
reitstellers der Anwendung angibt, einen dritten nu- 
merischen Wert, welcher die Art der Anwendungs- 
beschreibung (18(1)...) angibt, und weitere Num- 
mern, die sich jeweils ausschlieBlich auf einen der 
Anwendungsbeschreibung zugeordneten Interakti- 
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onskontext (19(1) ...) beziehen. 

9. Datenaustauschsystem nach einem der vorherge- 
henclen Anspruche, 

dadurch gekennzeichnet, daB die Kommunikati- 
onseinrichtung (14) so ausgefOhrt ist, daB sie den 
Datenaustausch in Datenblocke strukturiert, wel- 
che wenigstens zwei Teile umfassen. wobei ein er- 
ster Teil Daten sind, die insofern als operationsre- 
levant qualifiziert sind, als sie dazu verwendet wer- 
den, die Art der Operationen zu beeinflussen, die 
durch einen Befehl durchgefuhrt werden, wie er 
durch ein Kommunikationsgrundelement oder Da- 
ten angegeben ist, welche aus durchgefuhrten 
Operationen resultieren, wobei ein zweiter Teil in- 
sofern als sicherheitsrelevant qualifiziert ist, als er 
dazu verwendet wird, die Eignung zur Durchfuh- 
rung einer Operation oder die Akzeptierbarkeit von 
Daten in dem operationsrelevanten Teil zu bestim- 
men, urn in der Operation verwendet zu werden, 
oder die Beendigung der Operation oder die Kor- 
rektheit der resultierenden Daten nachzuweisen. 

10. Datenaustauschsystem nach Anspruch 9, 
dadurch gekennzeichnet, daB das Ausf uhrungspro- 
gramm (17) so ausgelegt ist, daB es bei Akzeptie- 
rung eines Kommunikationsgrundelements zur 
Durchfuhrung von in dem momentanen Interakti- 
onskontext (19(1) ...) spezifizierten Operationen je- 
de Operation als Teil einer vorbestimmten und fe- 
sten Folge von Aktionen durchfuhrt, die jeweils ge- 
sondert als Teil einer dem akzeptierten Kommuni- 
kationsgrundelement zugeordneten Prozedurbe- 
schreibung spezifiziert sind, welche Aktionen zu- 
mindest die folgenden Aktionen umfassen: 

a. Authorisierung der Verwendung des Kom- 
munikationsgrundelements; 

b. Entschlusselung der Operationsdaten oder 
eines Teils derselben; 

c. Durchfuhren eines Befehls mit Eingangsda- 
ten; 

d. Verschlusselung von Operationsdaten, die 
aus einer durchgefuhrten Operation resultie- 
ren; 

e. Berechnung eines Nachweises der Beendi- 
gung einer durchgefuhrten Aktion oder der Kor- 
rektheit der resultierenden Daten, urn in Sicher- 
heitsberechnungen verwendet zu werden. 

11. Datenaustauschsystem nach einem der vorherge- 
henden Anspruche, 

dadurch gekennzeichnet, daB die Datenverarbei- 
tungseinheit (5) bei Initialisierung des Datentrans- 
fers eine zufallige Transaktionsnummer erzeugt, 
die als Basis fur kryptographische Berechnungen 
dient. 



12. Datenaustauschsystem nach einem der vorherge- 
henden Anspruche, 

dadurch gekennzeichnet, daB einem Kommunika- 
tionsgrundelement ein spezifizierter Wert zugewie- 
s sen ist, der stets als Anforderung interpretiert wird, 
in einen neuen Interaktionskontext (19(1) ...) einzu- 
steigen. 

13. Datenaustauschsystem nach einem der vorherge- 
10 henden Anspruche, 

dadurch gekennzeichnet, daB es eine weitere Da- 
tenverarbeitungseinheit (4) umfaBt, welche die glei- 
chen Elemente wie die Datenverarbeitungseinheit 
(4) umfaBt, die optional in ihrem Speicher eine An- 
ts wendungsprogrammiererschnittstelle (10) enthal- 
ten kann, welche aus einem Programmcode be- 
steht, der so ausgefOhrt ist, daB er die Implemen- 
tierung zusatzlicher Computerprogramme erlaubt, 
urn Benutzern die Kontrolle Qber die Abfolge aus- 
20 getauschter Kommunikationsgrundelemente zu ge- 
ben oder urn die darin transferierten Daten zu be- 
einflussen oder die beim Austausch erfialtenen Da- 
ten zu lernen oder weiterzuverarbeiten. 

25 14. Datenaustauschsystem nach Anspruch 13, 

dadurch gekennzeichnet, daB das zum Einstieg in 
einen spezifizierten Interaktionskontext (19(1)...) 
verwendete Grundelement numerische Werte um- 
faBt, die bei Sicherheitsberechnungen in nachfol- 

30 genden Kommunikationen zu verwenden sind, ei- 
nen ersten, durch eine der Verarbeitungseinheiten 
erzeugten Zufallswert sowie einen zweiten, der 
Identifizierung dieser einen Verarbeitungseinheit 
dienenden Wert. 

35 

15. Datenaustauschsystem nach Anspruch 13, 
dadurch gekennzeichnet, daB jedes Kommunikati- 
onsgrundelement aus zwei oder mehr numerischen 
Werten zusammengesetzt ist, wobei ein erster Wert 

40 dazu verwendet wird, auf eine Prozedurbeschrei- 
bung einer dem Kommunikationsgrundelement zu- 
geordneten Aktion zu verweisen, wobei ein zweiter 
Wert aus einer f esten Zahl von Binarwerten zusam- 
mengesetzt ist, die durch das Ausfuhrungspro- 

45 gramm (12; 17) jeweils als Verweis auf ein einzel- 
nes Datenelement interpretiert werden. 

16. Datenaustauschsystem nach Anspruch 13, 
dadurch gekennzeichnet, daB jedes Kommunikati- 

50 onsgrundelement aus zwei oder mehr numerischen 
Werten zusammengesetzt ist, wobei ein erster Wert 
dazu verwendet wird, auf eine Prozedurbeschrei- 
bung einer dem Kommunikationsgrundelement zu- 
geordneten Aktion zu verweisen, wobei ein zweiter 

55 Wert dazu verwendet wird zu bestimmen, welche 
der zum externen Verweis in einem aktiven Interak- 
tionskontext (19(1) ...) verfugbaren Datenelemente 
verwendet werden, wahrend Antwortaktionen in 
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solcher Weise durchgef uhrt werden, daQ ein Daten- 
element ausgewahlt wird, wenn es einen Wert ent- 
halt, der mit dem zweiten Wert ubereinstimmt. 

17. Datenaustauschsystem nach Anspruch 13, 

dadurch gekennzeichnet, daG jedes Kommunikati- 
onsgrundelement aus zwei Oder mehr numerischen 
Werten zusammengesetzt ist, wobei ein erster Wert 
dazu verwendet wird, auf eine Prozedurbeschrei- 
bung einer dem Kommunikationsgrundelement zu- 
geordneten Aktion zu verweisen, wobei ein zweiter 
Wert aus einer Anzahl von Binarwerten zusammen- 
gesetzt ist, denen durch das Ausfuhrungspro- 
gramm (1 2, 1 7) spezielle Bedeutungen zugewiesen 
sind, urn bei der Interpretation von Datenformaten 
in dem Kommunikationsgrundelement und bei der 
Durchfuhrung von Antwortaktionen verwendet zu 
werden. 



Revendications 

1. Systeme d'6change de donnees comportant au 
moins une unite de traitement de donnees portative 
(5) comprenant un moyen de communication de 
donnees (14), un moyen de traitement (15) et un 
moyen de memorisation (16), ce dernier contenant 
un programme d'ex6cution (17), caracterise en ce 
que le moyen de memorisation (16) contient en 
outre au moins un contexte d'interaction (1 9(1 )...1 9 
(m)) presentant la structure cohSrente de donnees 
suivante: 

a. un jeu de primitives de communication de ba- 
se (A(1)...) qui sont acceptees dans le cas ou 
I'unite de traitement de donnees (5) communi- 
que avec une unite (4) similaire, lesdites primi- 
tives incluant au moins une primitive utilisee 
pour entrer de manfere selective dans Tun des- 
dits contextes d'interaction (19(1)....); 

b. unjeu de procedures de description (C(1)...) 
definissant les actions k r6aliser en r6ponse k 
chacune des primitives de communication ac- 
ceptees (A(1 ).,.), comprenant au moins une 
premiere procedure de description k realiser k 
I'activation du contexte d'interaction, et une 
derniere procedure de description k realiser im- 
mediatement avant la d6sactivation du contex- 
te; 

c. un jeu, eventueilement vide, memorise de 
maniere permanente ou calcuie, d'eiements de 
donnees qui sont disponibles pour etre utilises 
lorsque des procedures telles que d6finies 
dans les procedures de description (C(1)...) 
sont executees; 

d. un jeu, eventueilement vide, de references 
aux elements de donnees, lesquelles referen- 
ces sont associees aux procedures de descrip- 



tion (C(1 )...), lesdits elements de donnees sont 
aussi accessibles k d'eventuels autres contex- 
tes d'interaction et sont disponibles pour §tre 
utilises lorsque des procedures, telles que d6- 
s finies dans les procedures de description (C 

(1)...) sont executees; 

e. une liste de donnes, eventueilement vide, 
comprenant une liste de references (B(1)...) k 
des elements de donnees qui sont disponibles 

io pour une reference explicite comme partie 

d'une primitive de communication (A(1 )...) k uti- 
liser par la procedure de description (C(1)...) 
associee avec la primitive de communication; 

f . un jeu de conditions d'acces associe avec les 
is elements de donnees qui sont references en 

association avec les procedures de description 
(C(1)...); 

g. un jeu de conditions d'acces associe k la liste 
de references de donnees (B(1)...) de la liste 

20 de donn6es. 

2. Systeme d'6change de donn6es selon la revendi- 
cation 1 , caracterise en ce que le moyen de memo- 
risation (1 6) comprend en outre au moins deux con- 



25 textes d'interaction (19(1)...19(m)), au moins une 
description d'application (18(1)...) et un element de 
memorisation (20) contenant une reference au con- 
texte d'interaction courant qui est en vigueur, cha- 
que description d'application comprenant: 

30 

a. une liste de donnees contenant des referen- 
ces (E(1)...) k des elements de donnees, les- 
quelles references peuvent etre accessibles k 
deux ou plusieurs contextes d'interaction (19 

35 (1 )...) et peuvent etre compl6t6es par des ele- 

ments de donnees suppiementaires; 

b. un autre jeu de conditions d'acces associe 
auxdites references (E(1)...) ou auxdits ele- 
ments de donn6es suppiementaires et definis- 

40 sant des restrictions d'utilisation. 

3. Systeme d'6change de donn6es selon la revendi- 
cation 2, caracterise en ce que chaque description 
d'application (18(1 )...)) comprend aussi une librairie 

45 de procedures incluant des unites de code execu- 
table (F(1)...) qui peuvent §tre utilis6es par des pro- 
cedures de description de chaque contexte d'inte- 
raction associe avec chacune desdites descriptions 
d'application (18(1)...). 

so 

4. Systeme d'echange de donnees selon les revendi- 
cations 2 ou 3, caracterise en ce que le moyen de 
memorisation comprend au moins deux descrip- 
tions d'application (18(1)...) et des unites de code 

55 executable (G(1)...) qui peuvent §tre utilis6es par 
des procedures de description (C(1)...) de chaque 
contexte d'interaction (19(1)...) k I'int6rieur de cha- 
que description d'application (18(1)...) ou par cha- 
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que unite de code executable (F(1)...) de chaque 
librairie de procedures k I'interieur de chaque des- 
cription duplication (18(1)...). 

5. Systeme d'echange de donn6es selon Tune quel- 
conque des revendications 3 ou 4, caracterise en 
ce que les unites de code executable de la librairie 
de procedures sont ameiiorees en incluant une spe- 
cification d'utilisation de leurs parametres opera- 
tionnels en classes se rapportant k des attributs ap- 
partenant aux elements de donnees qui peuvent 
etre passes comme valeur reelle dans un calcul, le- 
quel calcul est execute seulement si les attributs de 
donnees et classes de parametres correspondent. 

6. Systeme d'echange de donnees selon Tune quel- 
conque des revendications 2 & 5, caract6ris6 en ce 
que le programme d'execution (17) comprend une 
reference k un contexte d'interaction pardefaut qui 
est utilise pour initialiser reiement de memorisation 
(20) contenant une reference au contexte d'interac- 
tion courant qui est en vigueur, dans le but de rea- 
liser une action finale apr£s detection d'une incohe- 
rence interne lors d'une reprise vers un etat normal 
de fonctionnement ou dans le cas ou le programme 
d'execution (17) est actif et qu'aucun contexte d'in- 
teraction explicite n'a et6 specifie par la primitive de 
communication regue k partir de I'unite de traite- 
ment de donnees opposee (4). 

7. Systeme d'echange de donnees selon Tune quel- 
conque des revendications precedentes, caract6ri- 
se en ce que le moyen de memorisation (16) con- 
tient un contexte d'interaction dedie qui inclut des 
Numeros d'ldentification Personnels et en ce que 
le programme d'execution (17) est prevu de man id- 
re k verifier les Num6ros d'ldentification Personnels 
deiivr6s par un utilisateur du systeme d'echange de 
donnees. 

8. Systeme d'echange de donnees selon I'une quel- 
conque des revendications 2 & 7, caracterise en ce 

. que chaque description d'application (18(1)...) com- 
prend une liste de valeurs numeriques qui est cons- 
truite de maniere k cr6er des identificateurs pour 
tous les contextes d'interaction (1 9(1 )..,) et com- 
prend au moins une premiere valeur numerique in- 
diquant un type d'application, une deuxieme valeur 
numerique indiquant une identification unique de 
I'entite fournissant ('application, une troisieme va- 
leur numerique indiquant la nature de la description 
d'application (18(1),..) et d'autres nombres se rap- 
portant chacun uniquement k un contexte d'interac- 
tion (19(1)...) associe avec la description d'applica- 
tion. 

9. Systeme d'echange de donnees selon I'une quel- 
conque des revendications pr6c6dentes, caracteri- 



se en ce que le moyen de communication de don- 
nees ( 1 4) est congu de maniere k st ructurer I'echan- 
ge de donn6es en blocs de donnees comprenant 
au moins deux parties, une premiere partie repr6- 

5 sentant des donnees et qualifi6e d'operationnelle 
en ce qu'elle est utilisee pour influencer la nature 
des operations realisees par une instruction telle 
qu'indiquee par une primitive de communication ou 
des donnees resultant d'operations realisees, une 

10 seconde partie qualifiee de securite en ce qu'elle 
est utilisee pour determiner la convenance de la 
realisation d'une operation ou I'acceptabilite des 
donnees, dans la partie operationnelle, qui doit §tre 
utilisee dans l'op6ration ou pour d6montrer I'ache- 

is vement de l'op6ration ou la validite des donnees re- 
sultantes. 

10. Systeme d'echange de donn6es selon la revendi- 
cation 9, caracterise en ce que le programme d'exe- 

20 cution (17) est pr6vu pour ex6cuter, k ('acceptation 
d'une primitive de communication afin d'executer 
des operations specifiees dans le contexte d'inte- 
raction courant (19(1)...), chaque operation comme 
une partie d'une sequence predeterminee et fixee 

25 d'actions dont chacune est specifiee separement 
comme une partie d'une procedure de description 
associee a la primitive de communication acceptee, 
lesquelles actions comprennent au moins les ac- 
tions suivantes: 

30 

a. autorisation de ('utilisation de la primitive de 
communication; 

b. decryptage des donnees operationnelles ou 
d'une partie quelconque de celles-ci; 

35 c. execution d'une instruction avec des don- 

nees d'entree quelconques; 
d. cryptage de donnees operationnelles quel- 
conques resultant d'une operation quelconque 
executee; 

40 e. calcul d'une preuve d'achevement d'une ac- 

tion executee quelconque ou de validite des 
donnees resultantes qui doivent etre utilisees 
dans des calculs de s6curit6. 

45 11. Systeme d'echange de donn6es selon I'une quel- 
conque des revendications precedentes, caracteri- 
se en ce que I'unite de traitement de donnees (5) 
produit, k Initialisation d'un transfert de donnees, 
un numero de transaction aieatoire, qui sert de base 

50 pour les calculs de cryptage. 

12. Systeme d'echange de donnees selon I'une quel- 
conque des revendications precedentes, caracteri- 
se en ce qu'une primitive de communication est af- 
55 fectee d'une valeur sp6cif \6e qui va toujours etre in- 
terpretee comme une requdte d'entr6e dans un 
nouveau contexte d'interaction (19(1)...). 
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13. Systeme exchange de donnees selon Tune quel- 
conque des revendications pr6c6dentes, caracteri- 
se en ce qu'il comprend une autre unite de traite- 
ment de donnees (4), constitute des memes 6I6- 
ments que I'unite de traitement de donnees (4), qui 
peut, en option, contenir dans sa mSmoire une in- 
terface pour programmeurs duplications (10) qui 
consiste en un code de programme con$u pour per- 
mettre la mise en oeuvre de programmes inlorma- 
tiques suppiementaires destines k donner aux uti- 
lisateurs la maitrise de la sequence des primitives 
de communication 6chang6es ou pour modifier les 
donnees transferees dans celles-ci ou pour appren- 
dre les donn6es re9ues au cours de I'echange ou 
r6aliser d'autres traitements sur celles-ci 

14. Systeme d'6change de donnees selon la revendi- 
cation 1 3, caracterise en ce que la primitive utilisee 
pour entrer dans un contexte d'interaction specifie 
(19(1)...) comprend des valeurs numeriques qui 
doivent etre utilisees dans des calculs de securite 
dans des communications ulterieures, une premie- 
re valeur aieatoire produrte par Tune des unites de 
traitement et une deuxieme valeur servant k identi- 
fier ladite premiere unite de traitement. 

15. Systeme d'echange de donnees selon la revendi- 
cation 13, caracterise en ce que chaque primitive 
de communication est composee de deux ou plu- 
sieurs valeurs numeriques, une premiere valeur 
etant utilisee pour designer une procedure de des- 
cription d'une action associee avec la primitive de 
communication, une deuxieme valeur etant compo- 
see d'un nombre fixe de valeurs binaires, chacune 
d'entre elles etant interpretee par le programme 
d'execution (1 2; 1 7) comme une reference k un ele- 
ment de donnee unique. 

16. Systeme d'6change de donnees selon la revendi- 
cation 13, caracterise en ce que chaque primitive 
de communication est composee de deux ou plu- 
sieurs valeurs numeriques, une premiere valeur 
etant utilisee pour designer une procedure de des- 
cription d'une action associee avec la primitive de 
communication, une deuxieme valeur etant utilisee 
pour determiner celui des elements de donnees dis- 
ponibles pour une reference externe dans un con- 
texte d'interaction actif (19(1)...) qui va etre utilise 
tout en executant des actions de reponse d'une telle 
manure qu'un element de donnee quelconque est 
seiectionne s'il contient une valeur qui correspond 
avec ladite deuxieme valeur. 

17. Systeme d'echange de donnees selon la revendi- 
cation 13, caracterise en ce que chaque primitive 
de communication est composee de deux ou plu- 
sieurs valeurs numeriques, une premiere valeur 
etant utilisee pour designer une procedure de des- 



cription d'une action associee avec la primitive de 
communication, une deuxieme valeur etant compo- 
see d'un certain nombre de valeurs binaires k qui 
des significations specifiques sont affectees par le 
s programme d'ex6cution (12, 17) et destin6e k §tre 
utilisee pour interpretation des formats de donnees 
dans la primitive de communication et pour I'execu- 
tion des actions de reponse. 
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